linux: the read-deny glob walk has a budget - #607

bubblewrap has no patterns, so a denyRead entry with glob syntax is
expanded on the host into the paths to mount over, on every wrap. That
walk listed through any symbolic link to a directory, wherever it led;
the only link it declined was one leading back up the tree. With a link
from a project to /usr and `**/.env` denied, each expansion listed
57,000 entries: 260 to 320 ms per command warm, seconds cold, and no
limit for a larger target. A sandboxed command can plant such a link.

A link whose target lies outside the pattern's tree is no longer listed
through. The tree is the pattern's literal starting directory and what
is under it, and a link is judged by where it resolves. Links that stay
inside are followed as before, and a link whose own name matches still
masks what it leads to. What this gives up is a file the pattern matches
only by a name that passes through such a link: macOS never covered it,
since patterns are matched against resolved paths there.

Where a matched link hides a directory outside the tree that the pattern
would have carried on into, nothing is bound back beneath it: it is
reported through unlistableDenyDirs like a directory the walk cannot
list. Unlisted, an allowed path beneath it would otherwise come back
with nothing masked.

The walk takes a budget, shared by all the denyRead patterns of one
configuration: 2,000,000 directory entries and 10 seconds, the clock
read before each listing and at each entry. Out of budget it throws and
hands nothing back, and the wrap is refused with LinuxSandboxProfileError
`deny_glob_too_large`, the walk's error as its cause. getFsReadConfig()
throws the same. A deny list cut short would leave readable what the
pattern was written to hide.

Each expansion logs one line under SRT_DEBUG: milliseconds, matches,
mounts, directories listed, entries looked at, links left unfollowed.

…llowed

A link out of a denyRead pattern's tree is not listed through, and what
the pattern would have matched beneath it is not denied. That was
recorded on the walk and written to the debug log; a caller had no way
to tell its user. getFsReadConfig() now lists each such link in
`unfollowedDenyLinks`, with the pattern that came to it, the link and
where it resolves. It informs and restricts nothing: no backend reads
it. The type is exported as UnfollowedDenyLink.

Where a link whose own name matches hides a directory outside the
pattern's tree, the expansion reported that directory as one it could
not list, so that nothing was bound back beneath it. The wrapper then
restores no allowed path at or beneath it, the paths that are always
writable included: with a link to a directory above the command's
temporary directory, every command failed, and an allowed write path
beneath such a directory stopped applying. Through the ancestor that
hides it, a second link could take the working directory along.

The report is taken out again. A directory outside the tree is never
listed, whether or not the link that leads there matches and whatever
is allowed beneath it; a matched link still hides its target whole; an
allowed path beneath it is bound back as written, as beneath a directory
denied literally. `unlistableDenyDirs` again names only a directory the
walk could not list, and the code that fills it is what it was.

What that gives up is what such a link used to add: what the pattern
matched beneath the allowed path through the link's name is not masked
again. A link out of the tree can only add to what a pattern covers. A
file whose real path is in the tree and matches is found by walking the
tree itself, so no link a sandboxed command creates takes a mask away.

The unfollowed links are handed back sorted by name, so that the list
and the debug line do not depend on the order a directory is read in.

Comments only: the JavaScript emitted with comments removed is
byte-identical for every file, and the test names are unchanged.

Kept: every invariant and what could be done without it, the
documentation of exported names, and the reasons for what is not done
the obvious way. Cut: how the code came to be as it is, narration of
the lines that follow, and explanations repeated at several sites.

…to change it

The default of 2,000,000 entries and 10 seconds refused every command
in a large monorepo: one `**/.env` pattern over 2.5 million entries
walks in about 7 seconds. Such a user waited before; refused, they
could not run anything, and nothing could raise the limit.

The defaults are now 20,000,000 entries and 60 seconds, and
`filesystem.denyReadGlobBudget` (`maxEntries`, `timeoutMs`) sets
others, from the initialized configuration, updateConfig() or one
wrap's customConfig. The refusal names the option.

README: wrapWithSandboxArgv() rejects the same way; the patterns share
one deadline; an over-budget configuration is accepted at initialize()
and every wrap of it spends the budget again.